Read the merge-method restriction against the live ruleset - #233

Closes #55

What was wrong

The parity walk's parameter table gave allowed_merge_methods the value
["merge","squash","rebase"] here and a verdict of Change owed, and the
subsection under it, ### Why the merge methods are not a style preference,
said in as many words that the restriction is not in place and that the only
thing standing against a squash merge is whoever picks the button.

Both statements were correct at every reading recorded on #55, from 2026-08-10
to 2026-08-30. Neither reproduces now:

$ gh api repos/Flowfin/lab/rules/branches/main \
    --jq '.[] | select(.type=="pull_request") | .parameters.allowed_merge_methods'
["merge"]

I found it by running the command before quoting the row back rather than by
reading the prose, which is the only way this class is found on this document -
a claim about a live setting reads the same whether or not the setting still
says it. This is the fifth instance recorded in that section and the first in
this direction: every earlier one was a gap the document claimed was closed or
a paste whose output had moved, and this one is a gap the document claimed was
open after it had been closed. A stale sentence claiming a hole that no longer
exists is as wrong as a stale sentence claiming one that does, and it is worse
placed, because it sits in the one row of the table a reader is most likely to
act on.

What changed

Four sentences, all inside the two subsections #55 built, all resting on the
older value.

• The row now reads ["merge"] on both sides, says it is the only row in this
  table whose value has ever moved, says what it read until 2026-08-30, and
  sends the reader to the subsection for the reason.
• The subsection carries the live paste and the reason at the restriction. The
  two paragraphs deriving it from record 0004's removal line and record
  0005's promotion range are unchanged; what is added is why the reason lives
  in this tree at all - the parameter is on a ruleset that is not here and
  carries no comment of its own, so a reader who finds ["merge"] and wants to
  know why has this section and nothing else.
• The table's preamble said all but the first row held the same value on both
  boards. All nine do now, because the first row is the one that moved and it
  moved towards the target.
• The signature subsection called allowed_merge_methods the only ruleset edit
  this document asks for. The one it still asks for is the required status
  checks Make the surviving checks required on the default branch #26 assembles.

The bound, stated rather than softened

The new paragraph says what the restriction is not: no check in this tree reads
allowed_merge_methods, a run here stays green whichever way it is set, and the
edit that restores squash and rebase costs about what the one that removed
them cost. What refuses a squash today is the platform, and what would notice it
being switched back is somebody re-running the pasted command. That is the same
bound ### What this walk cannot do states for the whole document, and this row
does not escape it.

Where the done-when of #55 stands

• A section listing every rule type both commands print for both boards.
  Met, and re-read for this change:

$ gh api repos/Flowfin/lab/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
pull_request
required_signatures
$ gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main --jq '.[].type'
deletion
non_fast_forward
required_status_checks
pull_request
required_signatures

Four types here and five at the target, which is the table under
### The rule types unchanged. The one difference left to explain is
required_status_checks, and its row already names #26 as what assembles it.

• Every parameter of the pull-request rule with kept or changed and a reason
  for each change. Met. Nine names on each side, and every row returns the
  value the table gives it:

$ gh api repos/Flowfin/lab/rules/branches/main \
    --jq '.[] | select(.type=="pull_request") | .parameters'
{"allowed_merge_methods":["merge"],"dismiss_stale_reviews_on_push":false,"dismissal_restriction":{"allowed_actors":[],"enabled":false},"require_code_owner_review":false,"require_extra_approval_for_unattributed_changes":true,"require_last_push_approval":false,"required_approving_review_count":0,"required_review_thread_resolution":false,"required_reviewers":[]}
$ gh api repos/Flowfin/jellyfin-plugin-sso/rules/branches/main \
    --jq '.[] | select(.type=="pull_request") | .parameters'
{"allowed_merge_methods":["merge"],"dismiss_stale_reviews_on_push":false,"dismissal_restriction":{"allowed_actors":[],"enabled":false},"require_code_owner_review":false,"require_extra_approval_for_unattributed_changes":true,"require_last_push_approval":false,"required_approving_review_count":0,"required_review_thread_resolution":false,"required_reviewers":[]}

• The merge methods restricted to the set that section names, with the reason
  written at the restriction. The restriction was made on the ruleset, which
  nothing in this tree reaches; the paste at the top of this body is it read
  back. The reason at the restriction is what this change writes.

• The section names issue Decisions of mine this plan does not take #46 for the one decision it does not take. Met,
  and unchanged here. The section names Decisions of mine this plan does not take #46 and also names
  docs/decisions/0023-signed-commits-on-the-default-branch.md, which is where
  the answer lives.

The means

Markdown prose in a document that already exists. The change is a repair to
four sentences of a walk, it adds no language, no runtime and no dependency,
and there is nothing here for a suite to test that a suite could test - which
is the same reason ### What this walk cannot do gives for the document as a
whole.

What I ran

The four commands CONTRIBUTING.md asks for before a push, at this head:

$ go build ./cmd/... ./internal/...
$ go vet ./cmd/... ./internal/...
$ gofmt -l cmd internal
$ go test -count=1 ./cmd/... ./internal/...

gofmt -l printed nothing, which is its passing result, and the suite passed.
The runner over this tree:

$ go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
27 decision records read
the time this run read is 2026-09-01T09:07:18Z
0 refused

No Go file is touched by this change, so none of the four could have been
expected to bite on it. They are run and reported because a change that skipped
them and a change that passed them read the same afterwards.

What this change does not do

It does not touch ## The gap this rests on or ## Which contexts arrive, and on which pull requests, which are #26's and #62's subjects, nor any row in
## The table. The whole diff is inside
### The pull-request rule, parameter by parameter,
### Why the merge methods are not a style preference and one sentence of
### The rule both boards carry now, and the condition it arrived ahead of.

It changes no setting. The ruleset edit this body reads back was made before
this branch existed and nothing here could have made it.

Reading

Nobody but me has read this change. The evidence above stands in place of a
second reader: every claim it makes is a command and its output rather than a
conclusion, and each one is re-runnable by whoever reads it next.